1. Field of the Invention
The embodiments of the invention generally relate to web services, and more particularly to systems and methods for implementing asynchronous broadcast web services.
2. Description of the Related Art
With the advent of open standards based technology, such as SOAP (Simple Object Access Protocol), UDDI (Universal Description Discovery Integration), and WS-Security (proposed security standards for secure web services such as those offered by IBM Corporation, Microsoft Corporation, and VeriSign, Inc.), there is a growing need to make the technology support enterprise level requirements. Until recently, a missing feature in the web services arena was the notion of a callback. Web services are most often thought of as remote procedure calls (RPC) using an extensible Markup Language (XML) format. Callbacks are often used for an asynchronous process where computer code requests notification when processing has completed or an event has occurred. This event might be a message in response to a callback or a subscription. This allows for a system to submit a request and not have to wait, but is assured of notification without polling for status. Polling occurs when an application or system requests a status to monitor a change or result. The change might be progress on an asynchronous task or alternatively the result of an asynchronous task. Polling is often used when the system does not support event driven operations.
As with many conventional standards for web service callbacks, the real task involves implementing the definition in a scalable performance oriented solution. By assuming that the system registers and receives a callback, there is a need for the development of a system for the wide distribution of such a callback system. Clearly, the register and callback in a one-off scenario is effective. Other conventional approaches utilize a framework supporting event subscription and event notification in the context of web services. Yet another conventional approach uses a standard topic based PubSub pattern using web services. Traditional broadcast level messaging is often referred to as publish subscribe (PubSub). Additionally, PubSub is a web-based matching service that instantly notifies a user when new content is created that matches the user's profile (i.e., subscription) and is available from PubSub Concepts, Inc., New York, N.Y., USA.
In an enterprise (i.e., business network) there are efficiencies that can be gained by leveraging the so-called “one-to-many paradigm.” The theory is that more than one user will request notification of the same event. However, one drawback of traditional PubSub systems is that they tend to maintain a socket connection between the client and server. A socket connection is a software object than connects a software application to a network protocol. Maintaining a socket connection ties up finite resource on the server and falls victim to the increasingly mobile client base and the intermittent connectivity experienced by many users on many devices.
Another drawback is the inflexible tightly coupled relationship between the client and server. While there are systems that have decoupled the publishing interface from the broadcast interface, there is a general notion that the entity registering for a callback will be the entity receiving the callback. However, this might not necessarily be the case. Moreover, general PubSub and messaging architectures do not provide callback functionality, as they are a technology component supporting messaging, and the manner in which they are used is not their primary concern.
Other conventional approaches provide potential standards for the XML messages, which a system may use to enable standardized callback and event notification. However, these conventional approaches tend to fail to describe the solution to communicate the messages. There are other conventional standards and current models for broadcast messaging. In each case there are advantages and disadvantages. The major advantages and disadvantages for the conventional approaches are described below. Specifically, the PubSub pattern is the most attractive. It offers the most obvious application at a design pattern level and even as an out of the box solution. As with the other conventional solutions, it too has its drawbacks.
PubSub requires persistent connections and vendor specific solutions to differentiate offerings in the marketplace. Open standards based solutions allow for more interoperability but some features and performance is lost with the standard generic interfaces. Moreover, PubSub solutions are generally so generic that workflow or routing of messages is done at another layer or in the applications leveraging the message bus. Out of the box solutions offer compelling message distribution, but tend to fail to minimize client/server dependencies and continued client/server connections.
The advantages of SOAP over PubSub is that it is fast and efficient in FAF (Fire and Forget) mode. However, the disadvantages are that SOAP over PubSub requires a persistent network connection, it requires a proprietary protocol (SOAP rides on top of the PubSub protocol), and a message delivery is assumed to be a subscriber. The advantages of SOAP over message queue systems are that SOAP has a robust message delivery, workflow integration, and an option for guaranteed delivery. However, the disadvantages are that SOAP is not as scalable as PubSub, it is not considered fast, it requires a proprietary protocol as SOAP rides on top of the underlying messaging protocol. The advantages of “Hand Rolled” web services callback are that it is simple, it supports many proposed standards, it offers loose coupling. However, the disadvantages involve scalability and performance issues.
Each of the conventional approaches is an example of the need for enterprise level callback and broadcast notification. Moreover, each of these proposed standards focuses on the messaging aspect of the solutions. The missing element in each of the approach is the engine (i.e., framework) that is used to support a PubSub-like operation with the disconnected flexibility of the common RPC or web services perspective. Therefore, there remains a need for such a web services broadcast engine (i.e., framework) capable of supporting a PubSub-like operation.